Web co-navigation

ABSTRACT

A system incorporating techniques described in this paper includes a shared session server system that enables clients to view and interact with content simultaneously. The system enables a first shared session client to send an event stream sufficient to depict results of interaction with the content at a second shared session client.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. provisional Ser. No. 61/442,105filed Feb. 11, 2011, entitled “Webpage Sharing and Collaboration System,Method, and Storage Medium,” which is incorporated by reference.

BACKGROUND

Browsing the Web is a solitary experience. It is possible to followrecent posts in comments sections of web pages or follow a blog, but theexperience, while relatively up-to-date, is still an observation ofcontent that is left behind by another; it is historical content.Existing systems for sharing an collaboration of webpages and websiteslimit users to transmitting the image of one system's desktop (thedesktop of the “primary user”) to one or more other systems. In suchsystems, a primary system installs software that transmits images of theprimary system's desktop to other users. The primary user essentiallysends the results of a browsing session as it happens to other users.The other users are relegated to bystanders viewing the results of theprimary user's session.

The foregoing example of the state of the art is intended to beillustrative and not exclusive.

SUMMARY

A system incorporating techniques described in this paper includessharing captured events and context around the events when browsing webcontent with participants in a shared browsing session. The techniquesare applicable to systems that enable interaction with a shared web pageby multiple users in real-time. A system implemented in accordance withthe techniques can include a web co-navigation system that couples a webcontent server to real-time shared session client devices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an example of system for providing a shared contentsession.

FIG. 2 depicts an example of a web co-navigation system.

FIG. 3 depicts a flowchart of an example of a method for sharinginteractions to web content.

FIG. 4 depicts a flowchart of an example of a method for receivingshared interactions to web content.

FIG. 5 depicts a flowchart of an example of a method for modifyingcontent for compatibility in a shared content session.

FIG. 6 depicts an example of a system for masking protected fields in ashared content session.

FIG. 7 depicts a flowchart of an example of a method for streamingreal-time mouse position.

FIG. 8 depicts a screenshot of an example of a web page with a firstshared connection client mouse cursor and a second (local) sharedconnection client mouse cursor.

FIG. 9 depicts a flowchart of an example of a method for modifyingsource code of a webpage to add an annotation.

FIG. 10 depicts a flowchart of an example of a method for determiningsession ID and remote URL from a requested URL.

FIG. 11 depicts a flowchart of an example of a method for downloading aremote page.

FIG. 12 depicts a flowchart of an example of a method for deriving HTTPheaders from a URL and HTTP method.

FIG. 13 depicts a flowchart of an example of a response to a sharedconnection client.

FIG. 14 depicts a flowchart of an example of a method for loading asession cache or querying a default search engine.

FIG. 15 depicts a flowchart of an example of a method for loading asession cache or querying a default search engine.

FIG. 16 depicts a flowchart of an example of requesting a new webpage.

FIG. 17 depicts a computer system on which components described in thispaper could be implemented.

FIG. 18 depicts a state diagram of a shared content synchronizationcache.

FIG. 19 depicts a flowchart of an example of a method for handlingiframes.

DETAILED DESCRIPTION

Specific implementations of the invention can be implemented in numerousways, including as a process; an apparatus; a system; a composition ofmatter; a computer program product embodied on a computer readablestorage medium; and/or a processor, such as a processor configured toexecute instructions stored on and/or provided by a memory coupled tothe processor. For the purpose of clarity, technical material that isknown in the technical fields related to the invention has not beendescribed in detail so that the invention is not unnecessarily obscured.

FIG. 1 depicts an example of a system 100 for providing a shared contentsession. In the example of FIG. 1, the system 100 includes a network102, a content server 104, a content client 106, a shared session serversystem 108, a network 110, and shared session client devices 112-1 to112-N (collectively referred to as the shared session client devices112).

In the example of FIG. 1, the network 102 is intended to include anapplicable communications network such as the Internet, a publicswitched telephone network (PSTN), an infrastructure network (e.g.,private LAN), or some other network that is capable of acting as a linkbetween the various components depicted in FIG. 1. The term “Internet”as used herein refers to a network of networks which uses certainprotocols, such as the TCP/IP protocol, and possibly other protocolssuch as the hypertext transfer protocol (HTTP) for hypertext markuplanguage (HTML) documents that make up the World Wide Web (the web). APSTN can include wired or wireless (e.g., 4G/3G/2G) network operated by,for example, a central provider. An infrastructure network that offerswireless connectivity can include wired and wireless devices incommunication with wireless access points (WAPs). The wired and wirelessdevices can include various network equipment including by way ofexample but not limitation a cable network head end, a DSL networkDSLAM, a fiber network aggregation node, and/or a satellite networkaggregation node.

In the example of FIG. 1, the content server 104 is coupled to thenetwork 102. The content server 104 can be implemented as a known orconvenient content server, such as a web content server.

In the example of FIG. 1, the content client 106 is coupled to thenetwork 106. The content client 106 can be implemented as a known orconvenient content client. The content client 106 is optional becausethe techniques described in this paper are applicable to co-navigatingclients, whereas the content client 106 is intended to juxtapose acontent client that may be operating in accordance with known orconvenient solo session processes in a time period overlapping a sharedsession involving the same web content.

In the example of FIG. 1, the shared session server system 108 iscoupled to the network 102. The shared session server system 108includes a shared content synchronization server engine 114 and areal-time shared session server engine 116. As used in this paper, anengine includes a dedicated or shared processor and, typically, firmwareor software modules that are executed by the processor. Depending uponimplementation-specific or other considerations, an engine can becentralized or its functionality distributed. An engine can includespecial purpose hardware, firmware, or software embodied in acomputer-readable medium for execution by the processor. As used in thispaper, a computer-readable medium is intended to include all mediumsthat are statutory (e.g., in the United States, under 35 U.S.C. 101),and to specifically exclude all mediums that are non-statutory in natureto the extent that the exclusion is necessary for a claim that includesthe computer-readable medium to be valid. Known statutorycomputer-readable mediums include hardware (e.g., registers, randomaccess memory (RAM), non-volatile (NV) storage, to name a few), but mayor may not be limited to hardware.

In the example of FIG. 1, in operation, the shared session server system108 parses a request received from, for example, the shared sessionclient device 112-1. In a specific implementation, the request includesa session ID/channel, a search term, or a URL. The shared session serversystem 108 can use this information to determine how to respond to theshared session client device 112-1 from a number of possible optionsincluding, for example, downloading a webpage corresponding to the URL,downloading a webpage corresponding to a default search engine's resultsof the search term, or retrieving the cached webpage from a data storecorresponding to the session ID. If a webpage is downloaded as opposedto being retrieved from cache, source code of the webpage is modified toconvert all URLs capable of changing location, including but not limitedto links, forms, and URLs within scripts, to a structure compatible withthe aforementioned parsing technique. Additionally, the source code canbe modified to direct the shared session client device 112-1 to downloadthe webpage's resources from the content server 104 or to download thewebpage's resources from the shared session server 108 (e.g., from aresource server).

Exceptions may be made or rules defined to remove or modify source codethat may prevent the content from displaying and/or behaving exactly asit would if downloaded from the content server 104 by the content client106 in an unshared session. In a specific implementation, collaborationfeatures, user interface, and other features are added to the sourcecode by the shared session server 108 prior to provisioning to theshared session client devices 112. The modified source code can bestored for later retrieval. The modified source code or the cachedcontent is sent to the shared session client devices 112.

The shared session client devices 112 are notified of changes to contentand are instructed to make a request to the shared session server 108with a URL structured to download the shared content from the cache.Users of the shared session client devices 112 can interact with theshared content through mouse, keyboard, and other events (e.g. hovers,scrolling, etc.) and/or using collaboration features. The shared sessionclient device 112-1 (or other one of the shared session client devices112) can send events or features that modify the shared contentstructure, e.g., a document object model (“DOM”) of the shared content,to the shared session server 108, which are distributed to andreplicated on the other shared session client devices 112 (e.g. byunicast, multicast, or broadcast). In a specific implementation, anevent, function, or change to the shared content structure thatoriginates on one of the shared session client devices 112 can bereplicated on a server instance of the shared content and the sharedsession server 108 can store the resulting content structure for laterretrieval.

In the example of FIG. 1, the network 110 is coupled to the sharedsession server system 108. The network 110 is depicted as distinct fromthe network 102 despite the fact that the network 110 can be consideredpart of the network 102. The distinction is drawn for illustrativepurposes. In a specific implementation, the network 110 includes awireless network. In such an implementation, one or more of the sharedsession client devices 112 can be implemented as a station. At aminimum, a station will include a processor, memory (though the memorycould be implemented in the processor), a radio, and a radio interface(though the radio interface could be implemented as “part of” theradio). In order to make a station useful in a user deviceimplementation, stations implemented on user devices will typically haveat least one input device and at least one output device, includinginput and output interfaces, if applicable.

A station, as used herein, may be referred to as a device with a mediaaccess control (MAC) address and a physical layer (PHY) interface to thewireless medium that comply with, e.g., cellular standards or the IEEE802.11 standard. A station can be described as “IEEE 802.11-compliant”when compliance with the IEEE 802.11 standard is intended to beexplicit. (I.e, a device acts as described in at least a portion of theIEEE 802.11 standard.) One of ordinary skill in the relevant art wouldunderstand what the IEEE 802.11 standard comprises today and that theIEEE 802.11 standard can change over time, and would be expected toapply techniques described in this paper in compliance with futureversions of the IEEE 802.11 standard if an applicable change is made.IEEE Std 802.11™-2007 (Revision of IEEE Std 802.11-1999) is incorporatedby reference. IEEE 802.11k-2008, IEEE 802.11n-2009, IEEE 802.11p-2010,IEEE 802.11r-2008, IEEE 802.11w-2009, and IEEE 802.11y-2008 are alsoincorporated by reference. In alternative embodiments, one or more ofthe wireless devices may comply with some other standard or no standardat all, and may have different interfaces to a wireless or other medium.It should be noted that not all standards refer to wireless devices as“stations,” but where the term is used in this paper, it should beunderstood that an analogous unit will be present on all applicablewireless networks. Thus, use of the term “station” should not beconstrued as limiting the scope of an embodiment that describes wirelessdevices as stations to a standard that explicitly uses the term, unlesssuch a limitation is appropriate in the context of the discussion.

The network 110, if it includes a wireless network, will typicallyinclude an internetworking unit (IWU) that interconnects wirelessdevices on the network 110 with another network, such as a wired LAN,and to the network 102. The IWU is sometimes referred to as a wirelessaccess point (WAP). In the IEEE 802.11 standard, a WAP is also definedas a station. Thus, a station can be a non-WAP station or a WAP station.In a cellular network, the WAP is often referred to as a base station.The network 110 can be implemented using any applicable technology,which can differ by network type or in other ways. The network 110 canbe of any appropriate size (e.g., metropolitan area network (MAN),personal area network (PAN), etc.). Broadband wireless MANs may or maynot be compliant with IEEE 802.16, which is incorporated by reference.Wireless PANs may or may not be compliant with IEEE 802.15, which isincorporated by reference. The network 110 can be identifiable bynetwork type (e.g., 2G, 3G, WiFi), service provider, WAP/base stationidentifier (e.g., WiFi SSID, base station and sector ID), geographiclocation, or other identification criteria.

In the example of FIG. 1, the shared session client devices 112 arecoupled to the network 110. As has been described, one or more of theshared session client devices 112 can be implemented as a station. Forexample, the shared session client devices 112 can be implemented aswireless user devices such as a phone, personal data assistant (PDA),computing device, laptop, net book, tablet, camera, music/media player,GPS device, networked appliance, or some other known or convenient userdevice; and/or various types of intermediate networking devices. Theshared session client devices 112 may or may not be wireless devices.

FIG. 2 depicts an example of a web co-navigation system 200. The system200 includes a load balancing engine 202, a real-time server 204, anevent replication datastore 206, a core server 208, a resource server210, an in-memory data server 212, a web client engine 214, and ascraping engine 216. One aspect of the disclosed subject matter is thereal-time shared browsing of web pages including mouse events (e.g.clicks, moves, hovers, etc.), annotations (e.g. highlights, comments,drawing, arrows, lines, etc.), and communication (chat, voice, etc.). Inanother aspect of the disclosed subject matter shared browsing sessionsare created and a history of all pages visited is stored persistentlyalong with all user activity (mouse events, annotations, communications,etc.) during the session. In yet another aspect of the disclosed subjectmatter all changes to the document structure (including but not limitedto text, attribute, node modifications, etc.) are replicated on theserver where they are stored persistently for later retrieval. Anadditional aspect of the disclosed subject matter is managing awhitelist of approved URLs a shared browsing session is enabled to view.Another aspect of the disclosed subject matter is creating new sharedbrowsing sessions directly from the browser's address bar or through anyuser interface. In another aspect of the disclosed subject matter eachnew shared browsing session can be given a name or a name can berandomly generated. An additional aspect of the disclosed subject matteris permitting shared browsing session (including all active clients) tobe started on, or redirected to, a new URL or a search term (using thedefault search engine), directly from the browser's address bar orthrough any user interface. Yet another aspect of the disclosed subjectmatter is permitting shared browsing sessions in all major web browsers(including, but not limited to, smart phones and other web-enableddevices) without the need for additional software or plugins.

In the example of FIG, 2, the load balancing engine 202 controlscommunication between real-time clients (not shown) and the real-timeserver 204. The load balancing engine 202 can improve the efficiencywith which requests or data exchanges are handled relative to a systemthat does not have load balancing under a set of network conditions. Ina specific implementation, the load balancing engine 202 has Nginxinstalled on it.

In the example of FIG. 2, the real-time server engine 204 can handlereal-time data exchanges from one real-time client to another. In aspecific implementation, the real-time server engine 204 can handleannotations (e.g., paint, pen-tool, comments, highlighting, etc.). In aspecific implementation, in operation, the real-time server engine 204accepts connections from various transports (e.g. websocket,flashsocket, ajax long polling, ajax multipart streaming, forever-frame,jsonp polling, etc.) depending on the capabilities of browsers of thereal-time clients. In a specific implementation, node.js is installed onthe real-time server engine 204. In one embodiment, the real-time serverengine 204 handles real-time requests on port 8080 and is responsiblefor streaming event data in real-time between clients and forpersistently storing modifications to webpage sources (e.g. mouseclicks, movements, scrolling, hovers, session updates, annotations,chat, etc.) in the event replication datastore 206.

A datastore can be implemented, for example, as software embodied in aphysical computer-readable medium on a general- or specific-purposemachine, in firmware, in hardware, in a combination thereof, or in anapplicable known or convenient device or system. Datastores in thispaper are intended to include any organization of data, includingtables, comma-separated values (CSV) files, traditional databases (e.g.,SQL), or other applicable known or convenient organizational formats.Datastore-associated components, such as database interfaces, can beconsidered “part of” a datastore, part of some other system component,or a combination thereof, though the physical location and othercharacteristics of datastore-associated components is not critical foran understanding of the techniques described in this paper.

Datastores can include data structures. As used in this paper, a datastructure is associated with a particular way of storing and organizingdata in a computer so that it can be used efficiently within a givencontext. Data structures are generally based on the ability of acomputer to fetch and store data at any place in its memory, specifiedby an address, a bit string that can be itself stored in memory andmanipulated by the program. Thus some data structures are based oncomputing the addresses of data items with arithmetic operations; whileother data structures are based on storing addresses of data itemswithin the structure itself. Many data structures use both principles,sometimes combined in non-trivial ways. The implementation of a datastructure usually entails writing a set of procedures that create andmanipulate instances of that structure.

In the example of FIG. 2, the real-time server engine 204 maintains datain the event replication datastore 206. Advantageously, the real-timeserver engine 204 can maintain a document data structure in the eventreplication datastore 206 sufficient to replicate on the server-sideclient-side changes to a document structure on a real-time client. Theevent replication datastore 206 includes a document source (cache),which the real-time server engine 204 loads into a document object model(“DOM”) and executes event handlers that were called on the real-timeclient. This results in the same changes on the server-side instance ofthe document structure in the replication datastore 206 that havehappened to the real-time client's instance. Advantageously, in aspecific implementation, methods or scripts in the document can beexecuted here in addition to event handlers. In a specificimplementation, the real-time server engine 204 can modify the cache ofthe event replication datastore 206 without a DOM by directly modifyingan event string. Once the server instance of the webpage matches theclient's instance, it is stored in the event replication datastore 206for later retrieval.

In a specific implementation, the event replication datastore 206includes current and historic webpage structures for a session,including any annotations. This permits clients joining late to see thelatest web page including annotations as well as permitting participantsto revisit a webpage that was previously viewed during the sessionincluding all annotations (e.g. the stored annotated webpage could showdynamic content such as news articles, advertisements and annotations asthe webpage existed when the page was viewed by the session).

The core-server 208 accepts connections passed from the load balancingengine 202. Generally, the core-server 208 responds to port 80 (client)requests and is responsible for serving webpages to the real-timeclients. In a specific implementation, the core-server 208 has node.jsinstalled on it.

The core-server 208 has logic to route requests based on the structureof the requested URL. Some examples of URLs that the core-server 208could route in various embodiments include:

URL Remarks / loads the home page /_monit is a call from monit/_loadbalancer is a call from Amazon Web Service (“AWS”) to check statusof core instance /search comes from search bar (either the home page ortoolbar) /share/* will get loaded into an iframe /* will load parentframe and pass remaining string to “/share” in an iframe

In the example of FIG. 2, the resource server 210 can be implemented asa proxy to download a requested webpage or other content from a webcontent server (not shown). The resource server 210 can also have somebasic scraping ability of CSS and js documents to optimize their displayon a third party domain (e.g. displaying “youtube.com”). In oneembodiment, the resource server 210 handles port 9000 requests and isresponsible for serving web content server static content (e.g. assets)and making modifications to the content's values. In a specificimplementation, the resource server 210 has node.js installed on it.

In the example of FIG. 2, the in-memory data server 212 can beimplemented as a key-value store or data structure server that keepsdata in memory for fast access and is able to persist data to a filesystem. The data can also be persisted to a relational database andloaded into memory again when needed to be accessed quickly. In oneembodiment, the in-memory data server 212 has Redis installed.

In the example of FIG. 2, the web client engine 214 makes calls andrequests to the web content server to retrieve a requested URL. The webclient engine 214 passes retrieved webpages to the core-server 208 forfurther handling.

The scraping engine 216 modifies a retrieved webpage's source code toensure its proper display and behavior on an external domain.Additionally, the scraping engine 216 modifies source code to the extentnecessary to enable co-navigation and to embed proprietary code thatenables changes to a document structure (e.g. annotations) and otherfeatures as well as a user interface for collaborating on andcontrolling the webpage.

FIG. 3 depicts a flowchart 300 of an example of a method for sharinginteractions to web content. The example of FIG. 3 is intended toillustrate how a first shared session client interacting with contentcan provide data sufficient to enable a second shared session client toobserve the results of the interaction. The flowchart 300, and otherflowcharts in this paper, are illustrated as serially arranged modulesand decision points, but it should be noted that the flowcharts could bereordered or arranged for parallel execution of certain modules.

In the example of FIG. 3, the flowchart 300 starts at module 302 withdisplaying web content including an interactive web content element.Content can include content elements, including interactive elements. Aninteractive element can be defined as an element that has an eventlistener bound to it. Thus, an interactive web content element “listens”for interactions with the web content element to which an event listeneris bound. Elements with which an event listener is not bound are notinteractive web content elements. It may be noted, however, that in aspecific implementation, certain interactive web content elements areprotected with permissions and in that specific implementation,described in more detail later, a user can interact with an interactiveweb content element and be denied permission to make a change that wouldnormally be appropriate given the interaction. Thus, interaction ispossible with interactive web content elements even if permission is notgranted. A user can typically interact with interactive web contentelements through, e.g., a web browser. For other applicable content, aknown or convenient content interface can be used.

In the example of FIG. 3, the flowchart 300 continues to module 304 withcapturing all java script events associated with native interactionswith the web content. Applicable known or convenient events can becaptured, such as change (e.g., to a drop down form, radio button, checkbox, etc.), mouse move, mouse over, mouse out, mouse down, mouse up,click, double-click, key down, key up, key press, and scroll. In aspecific implementation, the events include focus and blur.

In the example of FIG. 3, the flowchart 300 continues to module 306 withextracting, from a first java script event of the java script events,event type and target context associated with the interactive webcontent element. Event type identifies an event as change, mouse move,etc. Target context includes data, such as a mouse position, key event(e.g., Left-ALT is held down when the event occurs), or otherenvironmental condition or variable extant when an event is captured,that can be sent in association with the event type.

In the example of FIG. 3, the flowchart 300 continues to module 308 withidentifying a change that results from a native interaction of thenative interactions with the web content that will not result from thefirst java script event firing. For example, a native interaction toselect a drop-down menu and highlight an option in the drop-down menumay not result in the highlight occurring if the java script events aredutifully fired. The change augments the java script events that arestreamed from a first shared session client device to enable a secondshared session client device to display interactions with shared contentas they occurred on the first shared session client device.

In the example of FIG. 3, the flowchart 300 ends at module 310 withsending over a network interface data sufficient to enable display ofthe web content and results of the native interactions, including targetdata sufficient to identify the interactive web content element, thetarget context, the event type, and the change. Thus, a first sharedsession client device sends data sufficient to enable a second shardclient device to display interactions with shared content as theyoccurred on the first shared session client device.

FIG. 4 depicts a flowchart 400 of an example of a method for receivingshared interactions to web content. The example of FIG. 4 is intended toillustrate how a second shared session client can receive datasufficient to enable a second shared session client to observe resultsof interaction with shared content at a first shared session client. Inthe example of FIG. 4, the flowchart 400 starts at module 402 withdisplaying web content including a first interactive web contentelement.

In the example of FIG. 4, the flowchart 400 continues to module 404 withreceiving over a network interface target data sufficient to identifythe first interactive web content element, a context, an event type, andchange data sufficient to identify a first change. The target data,context, event type, and change are described by way of example abovewith reference to FIG. 3.

In the example of FIG. 4, the flowchart 400 continues to module 406 withidentifying the first interactive web content element using the targetdata. Because the target data includes data sufficient to identify thefirst interactive web content element, it is possible to identify thefirst interactive web content element using the target data.

In the example of FIG. 4, the flowchart 400 continues to module 408 withdetermining whether to apply the first change. The determination whetherto apply the first change can depend upon a number of variables, such asif the first change is necessary, differences between the browsers ofthe first shared session client and the second shared session client(e.g., one might use Firefox and one might use Internet Explorer, whichhave differing native interaction results).

In the example of FIG. 4, the flowchart 400 continues to module 410 withapplying the first change to a second interactive web content element.It should be noted that the first interactive web content element andthe second interactive web content element may or may not be the sameelement. This is because interaction with an interactive element cancause a change to the interactive element or with some other interactiveelement.

In the example of FIG. 4, the flowchart 400 continues to module 412 withconstructing a java script event from the context and the event type.After the change has been applied, which ensures that changes notcaptured in java script are made, the java script includes all otherrelevant changes. By capturing context and event type, the event can befired on the second shared session client in such a way that the resultsof interaction on the first shared client are displayed.

In the example of FIG. 4, the flowchart 400 ends at module 414 withdispatching the java script event on the second interactive web contentelement. It should be noted that although the results of interactionwith content at the first shared session client are captured andisplayed on the second shared session client, the display can beslightly different. For example, the first shared session client coulddisplay a cursor in black, while the second shared session clientdisplays the cursor of the first shared session client in blue and thesecond shared session client's own cursor in black.

FIG. 5 depicts a flowchart 500 of an example of a method for modifyingcontent for compatibility in a shared content session. FIG. 5 isintended to illustrate an example of how to modify source code of aretrieved webpage.

In the example of FIG. 5, the flowchart 500 starts at module 502 withcreating a document object model (DOM). The DOM can be created by, forexample, a shared content synchronization server engine (see, e.g., FIG.1, shared content synchronization server engine 114). The DOM can becreated by a scraping engine (see, e.g., FIG. 2, scraping engine 216),which, in a specific implementation, is included in the shared contentsynchronization server engine.

In the example of FIG. 5, the flowchart 500 continues to module 504 withmodifying or removing frame busting technique from source code. “Framebusting” code is code that is intended to prevent the loading of awebpage into another party's framed webpage. Module 504 is optionalbecause not all content will include frame busting techniques, but isbelieved to be desirable because at least some currently-available webcontent includes content incorporating frame busting techniques. Thus,in a specific implementation, the source code of the DOM is searched forsigns of “frame busting” for modification or removal. If there is framebusting code, the source code is modified to remove the offending code.It is important to note that frames are not required, but if frames areemployed, module 504 helps ensure the content is properly displayed.

In the example of FIG. 5, the flowchart 500 continues to module 506 withdetermining document type from the source code.

In the example of FIG. 5, the flowchart 500 continues to module 508 withadding URL base tag to header of source code.

In the example of FIG. 5, the flowchart 500 continues to module 510 withmaking modifications to source, specific to this host. The URL can bechecked for exceptions such as replacing embedded flash content thatdoes not have permission to be accessed by the document domain with aversion that is friendly to external embedding. As a means of example,and not of limitation, this is helpful for videos in webpages fromyoutube.com. These types of links are replaced with the cross domainfriendly embed tags that are made public. Module 510 is optional becausenot all content will include exceptions, but it is believed to bedesirable because at least some currently-available web content includescontent incorporating exceptions. If there is a need for one or moreexceptions, the source code is modified to address those exceptions forthat particular host.

In the example of FIG. 5, the flowchart 500 continues to module 512 withadding URL base tags, to URL resources and targets, to source code. Forexample, www.slashjoin.com could be appended to the front of every linkand/or form. In another example, webpages or websites that requiredtheir resources to be proxied, could have the tags script, style, image,etc., prefixed with by a shared content synchronization server engine(e.g. slashjoin.com:9000/). The webpages or websites could have thetags, etc. prefixed by a resource server (see, e.g., FIG. 2, resourceserver 210).

In the example of FIG. 5, the flowchart 500 continues to module 5014with adding shared session source code. The shared session source codecan include proprietary code of a shared session server. In a specificimplementation, the shared session source code changes documentstructure (e.g. additional commenting, collaboration, and editingfeatures), the user interface, and/or the scripts. The changes are usedby shared session clients and a real-time shared session server engine(see, e.g., FIG. 1, real-time shared session server engine 116; seealso, FIG. 2, real-time server engine 204) to provide functionality in ashared session.

In the example of FIG. 5, the flowchart 500 continues to module 516 withadding URL as a new entry into a list of locations this channel visited.This enables clients to retrace steps in a co-navigation session.

In the example of FIG. 5, the flowchart 500 ends at module 518 withsaving the modified session cache. For example, the modified sessioncache can be added to a datastore on an in-memory server (see, e.g.,FIG. 2, in-memory server .212).

Some examples of interactions captured at a first shared session client(see, e.g., FIGS. 1 and 3) and recreated at a second shared sessionclient (see, e.g., FIGS. 1 and 4) are described with reference to FIGS.6-16.

FIG. 6 depicts an example of a system 600 for masking protected fieldsin a shared content session. The system 600 includes a content server602, a shared content synchronization engine 604, shared connectionclients 606-1 to 606-N (collectively, shared connection clients 606), ashared connection server 608, a protected field detection engine 610, aprotected field masking engine 612, a protected field instance datastore614, a response queue datastore 616, a protected field contentdetermination engine 618, a request formatting engine 620, an originresponse synchronization engine 622, and an origin response contentcache datastore 624.

In the example of FIG. 6, in operation, the shared contentsynchronization engine 604 receives content (652) from the contentserver 602. The shared content synchronization engine 604 canalternatively, depending upon perspective, act as a content client ofthe content server 602 and as a proxy content server for the sharedconnection clients 606. In a specific implementation, the shared contentsynchronization engine 604 appears to the content server 602 to be acontent client (thus, the content server 602 may or may not be awarethat the shared content synchronization engine 604 also acts as a proxyto the shared connection clients 606). In a specific implementation, thecontent server 602 is controlled by an entity that is different than theentity controlling the shared content synchronization engine 604 and,accordingly, in such an implementation the content server 602 canalternatively be referred to as a third party content server.

In the example of FIG. 6, in operation, the shared contentsynchronization engine 604 sends the content (654) to the sharedconnection clients 606. In order to be part of a shared content session,the shared connection clients 606 must have joined the shared contentsession. Because all of the shared connection clients 806 areparticipants in the shared content session, the shared contentsynchronization engine 604 knows to send the content to each of theshared connection clients 606.

In the example of FIG. 6, in operation, the shared connection server 608receives respective event streams (656) from the shared connectionclients 606. The event streams include sufficient data to depict thecontent displayed on the shared connection clients 606 and results ofinteractions with the content, which is described in more detailelsewhere in this paper. In a specific implementation, the sharedconnection clients 606 are controlled by entities other than the entitythat controls the shared connection server 608.

In the example of FIG. 6, in operation, the protected field detectionengine 610 identifies protected fields (658) in content. Protectedfields are a subset of interactive content elements. Depending upon theimplementation, the shared content synchronization engine 604 can modifycontent source code to identify protected fields explicitly, making itrelatively trivial for the protected field detection engine 610 toidentify the protected fields, and/or the protected field detectionengine 610 can identify protected fields by observing their handles(e.g., password).

In the example of FIG. 6, in operation, the protected field maskingengine 612 makes data (660) input into the protected fieldunintelligible. Because the contents of the protected field presumablyare important (e.g., a password field, if entered correctly followed by‘return’, can cause the content server 602 or some other server toprovide new content), the data input into the protected field is storedin the protected field instance 614 prior to it being masked orotherwise rendered unintelligible.

In the example of FIG. 6, in operation, the shared connection server 608sends masked protected field data back to the shared connection clients606. It should be noted that in some cases it may be unnecessary to sendthe masked protected field data to certain ones of the shared connectionclients 606. For example, if a user of the shared connection client606-1 enters a value in a protected field, the shared connection client606-1 does not need to receive the masked value (662-1). In some cases,certain portions of a protected field might be provided back todifferent ones of the shared connection clients 606. For example, acooperative password that requires multiple users to enter a portion ofthe password can result in only portions of the masked value beingreturned to various ones of the shared connection clients 606.

In the example of FIG. 6, in operation, the shared connection serverreceives a submit event 664-1. The shared connection client 606-1 isillustrated as providing the submit event 664-1 for illustrativepurposes. The shared connection client 806-1 can send the submit event(664-1) as part of the event stream (656-1) and may treat the submitevent (664-1) no differently than any other event for the purpose ofreporting to the shared connection server 608. In addition, the sharedconnection server 608 may or may not be aware that the event resulted ina submit request, and could simply provide the submit request back toother shared connection clients 606 without recognizing a submit eventoccurred. Triggering the submit event has another effect: The sharedcontent synchronization engine 604 receives a submit request (664-2)when the submit event is triggered. Thus, the shared connection client606-1 sends both the submit event (664-1) as part of the stream ofevents (656-1) reported to the shared connection server 608 and thesubmit request (664-2) in the direction of the content server(typically) in order to request other content.

In the example of FIG. 6, in operation, the shared contentsynchronization engine 604 stores the submit request (666) in theresponse queue datastore 616. It may be noted that the shared contentsynchronization engine 604 may or may not know that the sharedconnection client 606-1 has provided the proper request (e.g., theprotected fields include the intended value), but there is notnecessarily a guarantee that submit request (666) from the appropriateone of the shared connection clients 606 is actually received beforerequests from another one of the shared connection clients 606.

In the example of FIG. 6, in operation, the shared connection server 608reports the submit event (668) to, e.g., the shared connection client606-N. The shared connection server 608 may or may not be aware that thesubmit event (668) is a submit event, and could treat the submit event(668) the same as other events that are reported to the sharedconnection client 606-N to enable the shared connection client 606-N todisplay the content displayed at the shared connection client 606-1,including results of interaction with the content.

In the example of FIG. 6, in operation, when the shared connectionclient 606-N receives the submit event (668), that triggers a submitrequest (670). The shared content synchronization engine 604 receivesthe submit request (670) before or after the submit request (666) of theshared connection client 606-1 (the submit request originator). There isno guarantee that the submit request (666) will be received before thesubmit request (670) and submit requests from other ones of the sharedconnection clients 606. Depending upon the implementation, it may be thecase that none of the requests include the proper value in the protectedfield (which means the request must be formatted before sending to thecontent server 602). Depending upon the implementation, it may be thecase that only the submit request originator provides the proper valuein the protected field.

In the example of FIG. 6, in operation, the protected field contentdetermination engine 618 determines the proper value for the protectedfield (674). This can be accomplished by consulting the protected fieldinstance datastore 614 to retrieve the proper value (676).Alternatively, the proper value could be in the submit request (664-2)of the original submit request generator, and the protected fieldcontent determination engine 618 can identify the field name (i.e., thecorrect field) and identify the original submit request generator (i.e.,the correct user).

In the example of FIG. 6, in operation, the request formatting engine620 formats a request (678) that is to be submitted to the contentserver 602 to include the proper values. The shared contentsynchronization engine 604, in its role as a content client, sends arequest (680) to the content server 602 and, receives a response (682).If the shared content synchronization engine 604 knows the identity ofthe request originator, the shared content synchronization engine 604may or may not, depending upon the implementation, send the response(684-1) directly to the shared content client 606-1 and also provide theresponse (684-2) to the origin response synchronization engine 622.Alternatively, the shared content synchronization engine 604 can providethe response (684-2) to the origin response synchronization engine 622and not send the response (684-1) to the shared connection client 606-1.

In the example of FIG. 6, in operation, the origin responsesynchronization engine 622 ensures that the response (684-2) from thecontent server 602 is properly distributed to the shared connectionclients 606. To aid in the distribution process, the origin responsesynchronization server engine caches (686) the response in the originresponse content cache 624. The origin response synchronization engine622 consults the response queue datastore 616 to determine (688) theshared connection clients 606 awaiting a response. The origin responsesynchronization engine 622 provides the responses (690), withmodifications as appropriate, to the shared content synchronizationserver, which sends the responses (692) to respective ones of the sharedconnection clients 606.

FIG. 7 depicts a flowchart 700 of an example of a method for streamingreal-time mouse position. FIG. 7 is intended to illustrate how when afirst shared connection client user moves a mouse, the first sharedconnection client provides data sufficient for a second sharedconnection client to display the mouse movement on the second sharedconnection client. In the example of FIG. 7, the flowchart 700 starts atmodule 702 with user moving mouse at first shared connection client.

In the example of FIG. 7, the flowchart 700 continues to module 704 withreceiving mouse coordinates from the first shared connection client. Themouse coordinates can be transmitted by, e.g., a web browser at theclient to a shared connection server. In a specific implementation, themouse coordinates can be received in an event stream along with otherevents.

In the example of FIG. 7, the flowchart 700 continues to module 706 withsending first shared connection mouse coordinates to a second sharedconnection client. The second shared connection client is representative(the mouse coordinates can be sent to all of the shared connectionclients on the same channel).

In the example of FIG. 7, the flowchart 700 continues to decision point708 with determining whether a mouse image has been created. If it isdetermined that a mouse image has not been created (708-N), then theflowchart 700 continues to module 710 with creating a mouse image. Themouse image can be created at a shared connection server and sent to thesecond shared connection client. The mouse cursor can be formatted to bethe same as the mouse cursor at the first shared connection client, orthe mouse cursor can be formatted such that it is clear upon visuallyinspecting the mouse cursor in a display that the mouse cursor is thatof the first shared connection client. For example, the cursor can havean identifier hovering near it, the cursor can be of a color that makesit identifiable as that of the first shared connection client, etc.Where there are many shared connection clients, it may be desirable toreduce the time a mouse cursor hovers (to reduce the number of mousecursors on the screen at one time), not display the mouse cursors ofcertain of the shared connection clients, display only the latest mousecursor, etc. Alternatively, the second shared connection client canreceive the mouse coordinates and create the mouse image at the client.

In the example of FIG. 7, the flowchart 700 continues to module 712 withmoving mouse image to specified coordinates. Typically, the mouse willbe moved at the client in response to receiving the event triggers fromthe shared connection server, though the mouse movement couldalternatively be handled at the shared connection server.

FIG. 8 depicts a screenshot 800 of an example of a web page with a firstshared connection client mouse cursor 802 and a second (local) sharedconnection client mouse cursor 804. The screenshot 800 also shows ashared connection chat feature in the upper right corner and severalpassages from the webpage have been highlighted. The screenshot 800 doesnot represent merely a video transmitted from one machine to another,but an actual webpage displayed in all of the client's web browsers whoare participating in the session/channel. All of the shared connectionclients participating in the session/channel can interact with thewebpage through their mouse and/or keyboard including clicking thelinks, typing, highlighting, commenting, or a host of othercollaboration, annotation, interaction, and/or document source changes.Any of these changes and/or interactions are then provided to the otherclients in the session/channel. Note also the history feature above thechat box which allows the participants of the channel to return topreviously viewed pages. Upon return to the previously viewed pages, auser would see all of the previous changes to that webpage. Also, notethe “menu” bar at the top of the webpage which can be used to enableadditional functionality. An additional feature is that all of the aboveare performed in near real-time (e.g. under normal circumstances, inunder a second).

FIG. 9 depicts a flowchart 900 of an example of a method for modifyingsource code of a webpage to add an annotation. In the example of FIG. 9,the flowchart 900 starts at module 902 with loading session cache forURL. A shared connection server loads the session cache with a requestedURL. In the example of FIG. 9, the flowchart 900 continues to module 904with retrieving client-side channel and URL cache. The shared connectionserver retrieves the client-side channel and URL cache. In the exampleof FIG. 9, the flowchart 900 continues to module 906 with modifyingcache source to add annotation. In the example of FIG. 9, the flowchart900 continues to module 908 with saving modified session cache todatastore, such as at an in-memory server.

FIG. 10 depicts a flowchart of an example of a method for determiningsession ID and remote URL from a requested URL. This figure is bestunderstood with an example, making reference to the elements depicted inFIG. 2. At module 1002 the pathname is retrieved by the core-server 208.In this example, the pathname is “slashjoin.com/gavin/gavinuhma.com”. Atdecision point 1004, the coreserver 208 determines if the pathname is aURL. If the pathname was a URL, the internal URL is set to the pathnameat module 1006; however, in this example the pathname is not a URL but acompound pathname containing both a session ID (also called a channelthroughout this disclosure); therefore, at module 1008, the core-server208 begins to parse the pathname by identifying the level-1 pathname. Inthis example the level-1 pathname is “gavin”. At decision point 1010,the core-server 208 determines whether the level-1 pathname is a searchterm which is determined by the existence of characters that are notallowed in the session ID (e.g. encoded characters, etc.) or by the lackof the level-1 pathname existing as a session ID in the data store.Because the level-1 pathname is not a search term, the session ID is setto the level-1 pathname at module 1012. Therefore, in this example, thesession ID is “gavin”. Next, the core-server 208 parses the remainder ofthe pathname to identify the level-2 pathname at decision point 1014. Iflevel-2 does not exist the session cache is loaded for the last pagethat was viewed on the session at module 1016. At module 1018 thecore-server 208 gets the level-2 pathname. At decision point 1020 thecore server 208 determines if the level-2 pathname is a search term. Ifnot, the internal URL is set to the level-2 pathname at module 1022.Therefore, in this example, the internal URL is set to “gavinuhma.com”.However, if the level-1 pathname or the level-2 pathname were searchterms, the internal URL would have been set to the default search engineURL with the addition of the level-1 or level-2 pathname, at modules1024 and 1026, respectively. After modules 1022, 1024, or 1026, the webclient engine 214 downloads the remote page at module 1028 from acontent server using the internal URL. The core-server 208 also loadsthe downloaded remote page into a new html page including an iframe atmodule 1030. Continuing the above example, the iframe source would beset to “http://slashjoin.com/share/gavin/gavinuhma.com” therebyprefixing the “/share” string so that the server will know how to handlethe page when the iframe is loaded).

FIG. 11 depicts a flowchart 1100 of an example of a method fordownloading a remote page. At module 1102 a new internal URL is set. Atmodule 1104, the web client engine 214 verifies that the domain namecontained in the internal URL is on the session's whitelist. If it isdetermined at decision point 1106 that the domain name is not on thesession's whitelist, the session is sent to the last authorized URL atmodule 1108 and the response is sent to the client 1110. However, if thedomain name is on the whitelist, the web client engine 214 determines atdecision point 1112 whether the webpage corresponding to the internalURL has a redirect cache corresponding to the URL in the data store. Ifthere is a redirect cache, the redirected URL is set as the internal URLat module 1102 and the flowchart 1100 continues as described previously.However, if there is not a redirect cache, the web client engine 214determines at decision point 1114 whether the webpage has a source cachecorresponding to the URL in the data store. If there is a source cache,at module 1110 the response is sent to the client. However, if there isnot a source cache, the protocol is determined and set at module 1116.Next, the web client engine 214 identifies if there is a port addresscontained in the internal URL at decision point 1118. If not, thedefault port is set for the protocol identified at module 1120.Regardless, the http headers and HTTP body are created at module 1122and the request is sent to the remote server at module 1124 by the webclient engine 214.

The web client engine 214 reads the HTTP status to determine if therequest was successful or there was an error at module 1126. If therequest was successful, the HTTP status should be 200 and the web clientengine 214 evaluates whether the response content is encoded at module1128. If the response content is encoded, the web client engine 214decodes the response body at module 1130. Regardless, the source cacheis set at module 1132 and any cookie at module 1134. The cookie, if any,is retrieved from the content server and stored in the datastore whichlinks the cookie to the session. This permits all of the cookies foreach session to be tracked and transmitted as necessary. The cookies areduplicated and sent in the responses to each of the clients. As a meansof example, and not of limitation, this permits everyone on a channel toshare the same shopping cart and/or share the same login to a website.The cookie and the body of the page (e.g. the source code) are cached onthe data store. Finally the response is sent to the client at module1110.

Returning now to module 1126, if the HTTP status is not 200, the webclient engine 214 checks if the HTTP status is 301 or 302 at decisionpoint 1136 (both indicating the webpage has moved). If the HTTP statusis 301 or 302, a cookie is set at module 1138, the redirect cache is setto indicate the URL of the moved webpage at module 1140, and the processstarts over at module 1102. The redirect cache is set to avoid makinganother request to a content server that will only return the sameredirect and consequently improves performance. However, if the HTTPstatus is not 301 or 302, the status is set to 404 (indicating thedesired webpage was not found) at module 1142 and the response is sentto the client at module 1110. Although only certain status codes arediscussed, one skilled in the art, with the assistance of thisdisclosure, could employ the teachings to handle other status codes inaddition to the ones specifically set forth herein.

FIG. 12 depicts a flowchart 1200 of an example of a method for derivingHTTP headers from a URL and HTTP method. At module 1202 the structure ofthe URL is determined by the core-server 208. The core-server 208evaluates whether the method (e.g. POST or GET) is set at decision point1204. If the method is not set, the default method is set to GET atmodule 1206. After module 1206 or if the method is set, the core-server208 determines if the method is POST at decision point 1208. If not, theheaders are set at module 1210. It is important to note that the headersare not simply forwarded from the client's original connection. If themethod was POST at decision point 1208, the content-type and other HTTPheaders are set to appropriate values at module 1212. Again, it isimportant to note that the headers are created and not simply forwardedfrom the client's original connection. After the headers are set ateither module 1210 or 1212, a new HTTP request object is created atmodule 1214. If the method is post at decision point 1216, the form issent at module 1218. Either after the form is sent at module 1218 or themethod is not POST at decision point 1216, the request is completed atmodule 1220. In a specific implementation, the request to download theremote webpage is called asynchronously so that the core-server 208 cancontinue to handle requests.

FIG. 13 depicts a flowchart 1300 of an example of a response to a sharedconnection client. If the HTTP status is 200 at decision point 1302, thecore-server 208 verifies if a session (e.g. channel) already exists atdecision point 1304. If the session already exists, the core-server 208checks to see if there is a cache at decision point 1306 and if thereis, the process proceeds to decision point Referring back to decisionpoint 1302, if the status was not 200, the core server 208 creates a 404error page at module 1310 and proceeds to decision point 1308. Referringback to decision point 1304, if the session has not been created, thecore-server 208 creates a new unique session ID at module 1312. Aftermodule 1312, and if the session did not have a cache at decision point1306, the retrieved webpage is scraped by the scraping engine at module1314 and the flowchart 1300 proceeds to decision point 1308.

At decision point 1308, the core-server 208 determines if the clientshould be redirected. If so, the status is set to 301 at module 1316 andthen, regardless of redirection, the response is sent to the client atmodule 1318. After the response is sent to the client at module 1318,the core-server 208 determines if a broadcast should be sent at decisionpoint 1320. If not, the process completes. Otherwise, a broadcast issent by the real-time server engine 204 to update the session for sharedconnection clients at module 1322 and the process completes. It isimportant to note that when responding to the client the headers andbody are created by the disclosed subject matter rather than simplyforwarded back.

FIG. 14 depicts a flowchart 1400 of an example of a method for loading asession cache or query a default search engine. At decision point 1402the core server 208 determines whether the client sent a URL. If a URLwas sent, at module 1404 the core-server 208 tells the real-time serverengine 204 to send a broadcast to the session's clients to update. If aURL was not sent at decision point 1402, the core-server 208 determinesif the session has a previous URL that was visited at decision point1406. If there was no previous URL, the core-server 208 determines thesession did not exist and uses the session name (e.g. channel name) as asearch term, retrieves the search results from the default search engineat module 1408, and sends the response to the client at module 1410.However, if the session did have a previously visited URL at decisionpoint 1406 or the broadcast occurred at module 1404, the core-server 208determines whether the session has a cache for the URL at decision point1412. If no cache for the URL exists at decision point 1412 the URL isused as a search term, the results retrieved from the default searchengine at module 1414, and the response is sent to the client at module1410. If however, the session does have a cache form the URL at decisionpoint 1412, then the response is sent to the client at module 1410.

FIG. 15 depicts a flowchart 1500 of an example of a method for loading asession cache or querying a default search engine. At decision point1502, the core server 208 determines whether a requested URL contains asession ID. If there is no session ID, at module 1504 the core server208 creates a random session ID and prefixes the random session ID tothe requested URL and the flowchart 1500 proceeds to module 1506. Ifthere was s session ID at decision point 1502, at decision point 1508the core server 208 determines whether the requested URL contains only asession ID. If so, at module 1510, the core server 208 identifies thelast URL viewed for the session ID and the flowchart 1500 proceeds tomodule 1506. If the URL does not contain only a session ID at decisionpoint 1508, the session ID and the URL are returned at module 1506.

FIG. 16 depicts a flowchart 1600 of an example of requesting a newwebpage. A shared connection client enters a new search at module 1602,which is received by the load balancing engine 202 at module 1604. Theload balancing engine 202 routes the request to the core server 208 atmodule 1606. At decision point 1608, the core server 208 determineswhether the shared connection client is already on a channel. If not,the core server 208 creates a channel at module 1610. At decision point1612 the core server 208 determines if a search string was a URL. Ifnot, the search string is processed through a default search engine atmodule 1614. If the search string was a URL, the web client engine 214requests the remote page from a content server at module 1616. The webclient engine 214 returns the remote page to the core server 208 whichis transferred to the scraping engine 216. At module 1618, the scrapingengine 216 modifies the remote page's source code to add collaborationscripts. The http response is then written to the client that initiatedthe request at module 1620. Finally, a request is sent to the real-timeserver engine 204, which instructs the real-time server engine 204 tosend an update message to other shared session clients connected to thesession at module 1622.

FIG. 17 depicts an example of a computer system 1700 on which techniquesdescribed in this paper can be implemented. The computer system 1700 maybe a conventional computer system that can be used as a client computersystem, such as a wireless client or a workstation, or a server computersystem. The computer system 1700 includes a computer 1702, I/O devices1704, and a display device 1706. The computer 1702 includes a processor1708, a communications interface 1710, memory 1712, display controller1714, non-volatile storage 1716, and I/O controller 1718. The computer1702 may be coupled to or include the I/O devices 1704 and displaydevice 1706.

The computer 1702 interfaces to external systems through thecommunications interface 1710, which may include a modem or networkinterface. It will be appreciated that the communications interface 1710can be considered to be part of the computer system 1700 or a part ofthe computer 1702. The communications interface 1710 can be an analogmodem, ISDN modem, cable modem, token ring interface, satellitetransmission interface (e.g. “direct PC”), or other interfaces forcoupling a computer system to other computer systems.

The processor 1708 may be, for example, a conventional microprocessorsuch as an Intel Pentium microprocessor or Motorola power PCmicroprocessor. The memory 1712 is coupled to the processor 1708 by abus 1770. The memory 1712 can be Dynamic Random Access Memory (DRAM) andcan also include Static RAM (SRAM). The bus 1770 couples the processor1708 to the memory 1712, also to the non-volatile storage 1716, to thedisplay controller 1714, and to the I/O controller 1718.

The I/O devices 1704 can include a keyboard, disk drives, printers, ascanner, and other input and output devices, including a mouse or otherpointing device. The display controller 1714 may control in theconventional manner a display on the display device 1706, which can be,for example, a cathode ray tube (CRT) or liquid crystal display (LCD).The display controller 1714 and the I/O controller 1718 can beimplemented with conventional well known technology.

The non-volatile storage 1716 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory1712 during execution of software in the computer 1702. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computer-readable medium” includes any type of storagedevice that is accessible by the processor 1708 and also encompasses acarrier wave that encodes a data signal.

The computer system 1700 is one example of many possible computersystems which have different architectures. For example, personalcomputers based on an Intel microprocessor often have multiple buses,one of which can be an I/O bus for the peripherals and one that directlyconnects the processor 1708 and the memory 1712 (often referred to as amemory bus). The buses are connected together through bridge componentsthat perform any necessary translation due to differing bus protocols.

Network computers are another type of computer system that can be usedin conjunction with the teachings provided herein. Network computers donot usually include a hard disk or other mass storage, and theexecutable programs are loaded from a network connection into the memory1712 for execution by the processor 1708. A Web TV system, which isknown in the art, is also considered to be a computer system, but it maylack some of the features shown in FIG. 17, such as certain input oroutput devices. A typical computer system will usually include at leasta processor, memory, and a bus coupling the memory to the processor.

In addition, the computer system 1700 is controlled by operating systemsoftware which includes a file management system, such as a diskoperating system, which is part of the operating system software. Oneexample of operating system software with its associated file managementsystem software is the family of operating systems known as Windows®from Microsoft Corporation of Redmond, Wash., and their associated filemanagement systems. Another example of operating system software withits associated file management system software is the Linux operatingsystem and its associated file management system. The file managementsystem is typically stored in the non-volatile storage 1716 and causesthe processor 1708 to execute the various acts required by the operatingsystem to input and output data and to store data in memory, includingstoring files on the non-volatile storage 1716.

FIG. 18 depicts a state diagram 1800 of a shared content synchronizationcache. The starting state of the state diagram 1800 is “no cache” 1802.Upon receiving a request from a shared session client A, the statetransitions to “processing cache” 1804. The edges departing state 1804are 1) when the cache is processed and shared session client A receivesa response or 2) when a second one or more requests are received fromsecond one or more shared session clients B. The second edge will bediscussed later.

In the example of FIG. 18, the transition from state 1804 to “cacheexists” 1806 is when the cache is processed and shared session client Areceives a response associated with the cached content. Shared sessionclient requests can be satisfied with the content in the cache.Accordingly, shared session client requests do not result in a statetransition (the cache still exists) and responses to the shared sessionclient requests similarly do not result in a state transition. The cachecan expire, which results in a state transition.

In the example of FIG. 18, the transition from state 1806 to “cacheexpired” 1808 is when the cache expires. However, shared session clientrequests can be satisfied with the content in the expired cache.Accordingly, shared session client requests do not result in a statetransition (the cache still exists even though it is expired) andresponses to the shared session client requests similarly do not resultin a state transition. A shared session client can make a prefetchrequest, which results in a state transition.

In the example of FIG. 18, the transition from state 1808 to “processingcache” 1804 is when a prefetch request is received from a shared sessionclient. The “processing cache” state was discussed above. In order tomaintain consistency with the state transition “client A response” theprefetch request is treated as a request by a shared session client A,though the shared session client A request transition from state 1802and the shared session client A prefetch request transition from state1808 may or may not be the same shared session client A.

In the example of FIG. 18, as was previously noted, the transition fromstate 1804 to “processing cache with queue” 1810 is when one or moreshared session client B requests are queued. It is undesirable for thecache to be processed for a shared session client B while the cache isbeing processed for a shared session client A. Cache processing can beimplemented as a first-come-first-served process that results inenqueueing all subsequent shared session client requests while the cacheis being processed.

In the example of FIG. 18, the transition from state 1810 to “cacheexists with queue” 1812 occurs when processing is complete and sharedsession client A is sent a response. The transition to state 1806 iswhen the shared session client B requests are dequeued and responses aresent to the one or more shared session clients B.

Advantageously, shared session client requests can be processed at thesame time by utilizing the synchronization cache. In a specificimplementation in order to capture the same random image for all sharedsession clients, the first request (which may or may not be the leader)caches first.

An issue related to content cache synchronization is resolvingconflicting client requests. Generally, it is desirable to know new andprevious locations. For example, if a first shared session clientrequests google then facebook and a second shared session clientrequests google, then it may be desirable to send the second sharedsession client facebook because the second shared session clientprobably needs to catch up. The sessions of each shared session clientare processed simultaneously, but due to environmental conditions, someshared session clients can have slower connections that other sharedsession clients. If the shared session is passing through multiple pagesat a relatively fast pace, shared session clients with slowerconnections might receive “responses” for content that they have not yetrequested.

Frames allow a visual HTML browser window to be split into segments,each of which can show a different document. An inline iframe placesanother HTML document in a frame. Unlike an object element, an inlineframe can be the “target” frame for links defined by other elements andcan be selected by a user agent as the focus for printing, viewing itssource, etc. There is currently no facility to give iframes unique idsbecause iframes are controlled by the target site.

FIG. 19 depicts a flowchart 1900 of an example of a method for handlingiframes. In the example of FIG. 19, the flowchart 1900 starts at module1902 with inspecting a page for iframes. In the example of FIG. 19, theflowchart 1900 continues to module 1904 with inspecting the pageperiodically for iframes (in case things change). An iframe has a source(e.g., google.ca) and is placed inside a web page. So, for example, aniframe with google.ca as the source and an iframe with facebook.com asthe source could co-exist within a web page. It is also possible to haveiframes with the same source (e.g., a first iframe with the sourcegoogle.ca and a second iframe with the source google.ca).

In the example of FIG. 19, the flowchart 1900 continues to module 1906with generating a unique id (uid) for the source of the iframe. The uidcan include an alphanumeric sequence of characters, such as ‘12345.’Depending upon the implementation, the uid can be a number that isincremented each time a uid is generated.

In the example of FIG. 19, the flowchart 1900 continues to module 1908with replacing the source of the iframe with a URL that references theuid. For example, the source of the iframe google.com can be replacedwith ‘12345.’ Where goinstant.com is a shared session server system,‘gonstant.com/12345’ can replace google.ca and other combinations ofgoinstant.com and a uid can replace other iframe sources.

In the example of FIG. 19, the flowchart 1900 ends at module 1910 withreceiving a browser request that requests a URL that references the uid.In the ongoing example, the request can include the source‘goinstant.com/12345.’ The shared session server is aware of the uidthat replaced the source of an iframe. (In this example, the source wasgoogle.ca.) Thus, the shared session server can redirect the iframe togoogle.ca upon receipt of the uid.

FIG. 20 depicts a flowchart of an example of a method for handlingscrolling events. In the example of FIG. 20, the flowchart 2000 startsat module 2002 with detecting a scroll event. In the example of FIG. 20,the flowchart 2000 continues to module 2004 with starting a timer.

In the example of FIG. 20, the flowchart 2000 continues to decisionpoint 2006 with determining whether the timer has expired. If it isdetermined that the timer has not expired (2006-N), then the flowchart2000 continues to module 2008 with decrementing the timer and theflowchart 2000 returns to decision point 2006 until the timer expires.When it is determined that the timer has expired (2006-Y), then theflowchart 2000 continues to module 2010 with checking scroll position.

In the example of FIG. 20, the flowchart 2000 continues to decisionpoint 2012 with determining whether scroll position =last scrollposition. If so (2012-Y), then the flowchart 2000 ends without reportingscroll position. If not (2012-N), then the flowchart 2000 continues todecision point 2014 with determining whether scroll position =lastreceived scroll position. If the scroll position is the same as a scrollposition that was last received (2014-Y), then the flowchart 2000 endswithout reporting scroll position. If not (2014-N), then the flowchart2000 continues to module 2016 with sending current scroll position toshared session clients, the flowchart 2000 returns to module 2004, andthe flowchart 2000 continues as described previously.

Advantageously, by utilizing the above-described technique, scrollingcan be accurately shared without getting into a loop when more than oneshared session client is scrolling at the same time.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present invention, in some embodiments, also relates to apparatusfor performing the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may comprise a generalpurpose computer selectively activated or reconfigured by a computerprogram stored in the computer. Such a computer program may be stored ina computer readable storage medium, such as, but is not limited to,read-only memories (ROMs), random access memories (RAMs), EPROMs,EEPROMs, magnetic or optical cards, any type of disk including floppydisks, optical disks, CD-ROMs, and magnetic-optical disks, or any typeof media suitable for storing electronic instructions, and each coupledto a computer system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, the present invention is not described with reference toany particular programming language, and various embodiments may thus beimplemented using a variety of programming languages.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

Text associated with potential future claims follows:

A method comprising: displaying web content; detecting interaction, witha web content element, intended to trigger an event in association withthe web content element; determining a permission to interact with theweb content element; preventing the interaction from triggering theevent when it is determined there is no permission to interact with theweb content element; triggering the event when it is determined there ispermission to interact with the web content.

A method comprising: establishing a shared browsing session; displayingweb content; receiving an indication through a user interface that ashared browsing session is in presenter mode; sending the indicationover a network interface data sufficient to display the web content,including changes made to the web content, in real-time to a participantwith limited permission to make changes from interacting with the webcontent. The method, further comprising: tying a permission to a target,event type, user, or a combination of these.

A method comprising: displaying a live web page with a local cursor;receiving a captured sequence of java script events on a networkinterface; applying a change that will result from a native event firingon a remote device; playing the captured sequence of java script events;overlaying the results of playing the captured sequence of java scriptevents onto the live web page including a remote cursor.

1. A method for sharing interactions to the web content, comprising: displaying web content including an interactive web content element; capturing all java script events associated with native interactions with the web content; extracting, from a first java script event of the java script events, event type and target context associated with the interactive web content element; identifying a change that results from a native interaction of the native interactions with the web content that will not result from the first java script event firing; sending over a network interface data sufficient to enable display of the web content and results of the native interactions, including target data sufficient to identify the interactive web content element, the target context, the event type, and the change.
 2. A method for recreating shared interactions with web content, comprising: displaying web content including a first interactive web content element; receiving over a network interface target data sufficient to identify the first interactive web content element, a context, an event type, and change data sufficient to identify a first change; identifying the first interactive web content element using the target data; determining whether to apply the first change; applying the first change to a second interactive web content element; constructing a java script event from the context and the event type; dispatching the java script event on the second interactive web content element.
 3. The method of claim 2, wherein the first interactive web content element and the second interactive web content element are the same.
 4. The method of claim 2, further comprising: determining whether to apply a second change to the first interactive web content element; if it is determined to apply the second change: obtaining data sufficient to apply the second change from any of the target data, the context, the event type, and a combination of these; applying the second change.
 5. The method of claim 2, further comprising: determining whether to apply a second change to the second interactive web content element; if it is determined to apply the second change: obtaining data sufficient to apply the second change from any of the target data, the context, the event type, and a combination of these; applying the second change. 